Example-Centric Programming (2004)
background
programming は抽象化の組み重ね、抽象的なものを理解するのは難しい
抽象的なものごとを理解する best way は example を使って study すること (僕もそう思うけど本当か?こういう人間の認知みたいな話の根拠ってどうやって主張すればいいのかね)
Accordingly in practice we tend to understand code by working through examples in our head. We are mentally running an interpreter when there is a computer sitting right in front of us!
まあ分かる
どんなもの?
Example Centric Programming というプログラミングスタイルを導入するためにEclipse Plugin EGを作ったよ
ユーザーは明示的にcode exampleを書いておき、プログラムを実装する際はとなりでcode exampleが自動的に実行
https://scrapbox.io/files/6093d7cf6025b7001c35521c.png
右上は実装中のプログラム(factorial)、下にexampleがあり、左にはプログラムの挙動をtraceしたものが表示される
左のtraceをhoverすると、右のプログラム上にどこのコードが実行されたかがハイライトされる、またそのときのフィールドの値も見ることができる(traceを見ながらかんたんに動かせるデバッガみたいな)
trace内にassertionを入れて、成功するかどうかもシュシュっと調べられる
先行研究と比べてどこがすごい?
プログラミング教育においてexampleは重要なので、このツールは教育に便利
単純にテストを実行するのではなく、exampleに対してデバッガから得られる情報をユーザーにわかり易く提供する
デバッガを使うときはプログラミングのメンタルモデルからスイッチする必要があるが、このツールはシュッとデバッガ情報を得られるので思考プロセスを妨げない
単体テストを常に実行するのと比べて、このツールはよりインタラクティブデバッガのような動きをしてくれる
Conventional unit testing is “black-box” – it can only work through the API.
一方、traceの中にassertionを入れるのは "glass-box" testing (造語?)なのでプログラムのより深い洞察を得られる
技術や手法のキモはどこ?
どうやって有効だと検証した?
議論はある?
次に読むべき論文は?
A common solution for associating tests with code is to embed them in nearby comments – perhaps first done in Poplar 19. An alternative approach, taken in JUnit 13, is to put tests into a parallel class hierarchy using naming conventions. This approach has the disdvantages of weighing down tests with boilerplate wrapper code, and also making the connection between testing and tested code distant and implicit.